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(57) ABSTRACT 

A method of communication between requester and target 
devices in a computer system having a multiple bus archi- 
tecture. The method supports deferred transactions of cache 
line read requests over a host bus, e.g., the Pentium II or 
Pentium Pro (P6) bus. The method employs a host bridge to 
issue deferred transactions over the P6 bus without inter- 
rupting or involving the main processor. The method com- 
prises the act of establishing a handshake with a host master 
and issuing a request over the host bus. The method further 
comprises the act of acknowledging the request and trans- 
mitting a deferred response to the requester. 

13 Claims, 5 Drawing Sheets 
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METHOD OF PEER-TO-PEER MASTERING clock rate may be two, three, or four times the speed of the 

OVER A COMPUTER BUS bus. The P6 bus employs "packet" transmission to transmit 

data the same way that a network transmits packets. A data 

RELATED APPLICATIONS packet is known as a chunk which may be up to 64 bits. The 

5 P6 bus supports split transactions. Accordingly, a P6 pro- 

The subject matter of U.S. Patent entitled SYSTEM FOR cessor sends an address and then releases the bus for use by 

PEER-TO-PEER MASTERING OVER A COMPUTER other bus requesters while waiting for the target device (e.g., 

BUS, filed on even date herewith, issued as U.S. Pat. No. a main memory) to respond. When the target is ready to 

6,073,198 is related to this application. respond, the target returns the requested data over the data 

bus in 64-bit packets. 

BACKGROUND OF THE INVENTION The maximum data transfer that is supported by the P6 

r u i * processor bus is four 64-bit wide transfers, commonly 

1. Meld ot the Invention referred to as a "cache line" transfer. As noted above, the P6 
The invention relates generally to information processing processor supports split transactions. This feature is often 

systems, such as a personal computer (PC). More characterized as a "deferred response" whereby a target 

particularly, the invention relates to processing transactions 15 device defers its response to a request by a requester. A 

in a computer system having multiple bus architecture. deferred response allows the P6 bus to be freed to execute 

2. Background of the Related Art other requests while waiting for the response from a device 
WJ , . . with relatively long latency. A single P6 processor may have 
Modern computer systems, such as personal computers tQ fouf tnmsac f ions 0 ^ i&nd ^ g at lh H c samc lim J 

(PC*), process an enormous amount of Ration m a 20 an 

relatively short time. To perform its sophisticated functions, tcr { ^ a 6 multip i e bus ^ iicc - 

a computer system typically includes a main processor, shown ^ nG ^ a main ^ oa £ SOT CPU u0 is 

memory modules, various system and bus control units, and connected t0 a Ho st bus 120. AHost bridge 130 connects the 

a wide variety of data input/output (I/O) devices. Typically, Host bus 12 q to a secondary bus PCI1 bus 140. One or more 

these computer devices communicate control and data sig- 25 input/output devices IOD1 142 is connected to the PCI1 bus 

nals in accordance with a predetermined signal protocol. 140. The Host bridge 130 supports communication between 

However, with the employment of a multiple bus PCI devices, e.g., IOD1 142, and devices present on the Host 

architecture, these devices often communicate across a plu- bus 120 or elsewhere in the system. Another Host bridge 150 

rality of bus protocols and bridging devices. A bridging is often employed to connect another PCI2 bus 160 to the 

device performs protocol conversion between two buses, 30 Host bus 120. Moreover, other I/O devices, e.g., IOD2 162, 

thereby allowing each device involved in a transaction to are connected to the PCI2 bus 160. Similarly, the Host 

know how and when the other device is going to perform a bridge 150 supports communication between PCI devices, 

particular task. e.g., IOD2 162, and devices present on the Host bus 120 or 

A transaction over a particular bus normally involves a elsewhere in the system, 

requesting device (the "requester") and a responding device 35 A bus transaction over the Host bus 120 is often in the 

(the "target"). The requester requests the transfer of data or form of a read request issued by a requester device. For 

a completion signal from a target in the system. The request example, in single chunk requests, the IOD1 142 on the 

typically includes a number of control bits indicating the PCI1 bus 140 may issue a read request to the IOD2 162 on 

type of request and an address of the desired data or device. the PCI2 bus 160. The purpose of the read request may be 

The target, in turn, responds to the transaction by sending a 40 to obtain data being processed by or available at the IOD2 

completion signal along with any data if necessary. With the 162. The Host bridge 130 receives the read request from the 

presence of various devices acting as requesters and targets IOD1 142, decodes the address from the read request, and 

in the system, bus protocols often include the ability to issues a single chunk (i.e., 64 bits) read request over the Host 

handle multiple transactions among multiple devices con- bus 120 to the PCI2 bus 160. A cache line read may not be 

currently. One example of such a bus is the pipelined bus 45 issued to the PCI2 bus 160 because a PCI bus does not 

which allows requests by various requesters to be pending support a cache line read (i.e., four 64 bits). Acache line read 

(i.e., unfulfilled) over the bus at the same time. The incor- on a PCI bus triggers a retry request after the target transfers 

poration of separate data and address buses makes this one or more words to the requester. The retry request is often 

possible. In a pipelined transaction, a requester sends a triggered because a PCI device may need to execute other 

request on the address bus, and a target returns a reply on the 50 requests before servicing the read request. A retry request is 

data bus. Multiple requesters may send multiple requests problematic over a PCI bus because speculative reads are 

over the address bus, and multiple targets may respond in the not permitted. A speculative read is a read operation (usually 

same order of the requests over the data bus. In a special in response to a retry request) of an already read data. Hence, 

pipelined bus, commonly referred to as the split transaction in response to the single chunk read request by the Host 

bus, the order of the responses does not have to occur in the 55 bridge 130, the Host bridge 150 detects the request and 

same order as their corresponding requests. Each transaction issues a single chunk read request to the IOD2 162 on the 

is tagged so that the requester and the target keep track of the PC12 bus 160. 

status of the transaction. This characteristic permits maxi- There are several inherent inefficiencies with single chunk 

mum utilization of the pipelined bus by effectively in ere as- requests. A single chunk request does not utilize a host bus 

ing bus bandwidth. This advantage, however, is obtained at $q efficiently. In view of its limited bandwidth occupancy, a 

a cost of experiencing a higher latency than when a request single chunk request slows down the computer system, 

is held during the pendency of a transaction. Moreover, unless retried, a single chunk request ties up the 

The Pentium II or Pentium Pro processor is an example of host bus until fulfilled. A defer transaction is not an option 

a processor which supports a pipelined bus, commonly for PCI devices because, as a bus requester, a host-PCI 

referred to as the P6 bus. The P6 bus includes a 64-bit 65 bridge does not support deferred transactions, 

external data bus and a 32- or 36-bit address bus. The speed Therefore, there is a need in the technology to make a 

of the P6 bus may be 66 or 100 MHz, and the processor more efficient use of a host bus, e.g., the P6 bus. The 
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utilization of full bus bandwidth on the host bus should be 226 may be any PCI compatible devices, such as a LAN 

accommodated on secondary buses, e.g., the PCI bus. More interface, a SCSI card, an audio card, or a graphics card. One 

particularly, cache line requests, which are accommodated or more I/O devices may be connected to the IOD bus 220, 

by the host bus, should be supported by secondary buses. e.g., Bus Mastering IOD (BMIOD) 230. The BMIOD 230 

5 may be any type of I/O device such as a hard disk, a 

SUMMARY OF THE INVENTION CD-ROM, or similar. 

To overcome the above-mentioned problems, the inven- Another Host bridge HB2 232 may also be connected to 

tion provides a system for executing peer-to-peer mastering the Host bus 210 to support communication between the 

over a host bus in a computer system. The system includes Host bus 210 and other buses in the system, such as a PCI2 

a host bridge which performs deferred bus transactions in a 10 bus 236, and a memory bus 240. The HB2 232 may be 

computer system having a multiple bus architecture. The identical to the HB2 214, or may be a 82454KX/GX PCI 

host bridge supports communication among multiple input/ Bridge manufactured by Intel Corporation. The memory bus 

output devices (IODs) without interrupting or involving the 240 supports communication between the HB2 232 and a 

main processor. main memory 244. The PCI2 Bus 236 supports communi- 

In one embodiment of the invention, a method of com- 15 catioa ^tween the HB2 232 and multiple I/O devices, e.g., 

munication between a requester and a target device is IOD3 248 and IOD4 252. The devices IOD3 248 and IOD4 

provided. The method comprises the act of establishing a 252 ma y bc ^ PCI compatible devices, such as a LAN 

handshake between an IDE Controller and a host master, and interface, a SCSI card, an audio card, or a graphics card. In 

issuing a request by the host master over a host bus. The ^ embodiment, the PCU bus 218 and PCI2 bus 236 are 

method further comprises the act of acknowledging the 20 standard peripheral component interconnect (PCI) buses 

request, and transmitting a deferred response to the which conform to the PQ Local Bus Specification (Revision 

requester. 21 or latcr )- 

In this embodiment, any one of the devices CPU1 204, 

BRIEF DESCRIPTION OF THE DRAWINGS CPU2 208, and HB1 214 may issue "deferred" transactions 

The above and other aspects, features and advantages of 25 oa Host bus 210. The deferred transaction capability 

the invention will be better understood by referring to the al [ ows the . Ho ? bu f i0 be freed r to execute other ret * uests 

following detailed description, which should be read in wh ? e ™ lim f *>' th f res P ot ? e f * om a ^ uest t0 a device 

conjunction with the accompanying drawings, in which: ^^ y „ 1 ?S i , l t !° cy ' °™ ° f thc t devioes C ™ 1 

* . . fi . r , j. r , 204, CPU2 208, HB1 214, and HB2 232 may have up to four 

FIG. 1 is a functional block diagram of an exemplary 30. * , * *i_ i_ r 

& F ' transactions outstanding at the same time. The number of 

compu er ar ware ayou . transactions that may target a particular bus device is con- 

FIG. 2 is a functional block diagram of a computer system figured separately from the total number of transactions 

employing one embodiment of the invention. allowed on the bus. Each of the HB1 214 and HB2 232 may 

FIG. 3 is a functional block diagram of the Host bridge as accept up to four transactions into its in-order queue (IOQ) 

used in the computer system of FIG. 2. 35 (not shown in this figure) that target its associated buses. 

FIG. 4 is a flow chart describing the execution of a bus Hence, for example, the HB1 214 may have a read request 

transaction in the computer system of FIG. 2. directed to IOD3 248 and a read request directed to the main 

FIG. 5 is a timing diagram for a deferred transaction as memory 244 pending at the same time on the Host bus 210. 

executed by the internal control bus of FIG. 3. ^ A bus mastering IOD-type device, e.g., BMIOD 230, issues 

a read request to the HB1 214 over the IOD bus 220, having 

DETAILED DESCRIPTION OF THE the main memory 244 as its destination. Another bus mas- 

INVENTION tering IOD-type device may issue another read request to the 

A detailed description of the system for peer-to-peer HB1 214 over the 100 bus 22 °. havin S lhe IOD3 248 « its 

mastering over a computer bus is provided below. In 45 tai B ct - ^ HB1 214 > in lurn » ma y ^sue ^th read requests 

describing particular embodiments of the invention, the ^ a deferred capability over the Host bus 210. The HB2 

disclosure is not intended to limit the enumerated claims, but 232 detects and delivers each read request to its intended 

to serve as a particular example of the invention. destination, i.e., to the main memory 244 via the memory 

The invention provides a system for peer-to-peer master- bu 5 240 > or 1003 248 via * e rci2 bus 236 - In ?™ of the 

ing over a computer bus, such as the Pentium II or Pentium 50 deferred res P ons€ feature > lhe Hosl bus 210 15 freed U P 10 

Pro ("P6") bus. Other processors which support pipelined execute ott ! er ~cuons, each read request may 

transactions may also be used. FIG. 2 is a functional block rema ^ Pf°**8 al the same tUDe ' umJ lhe maiD memor y 244 

diagram of a computer system employing one embodiment and I0D3 248 m read y 10 res P° nd 10 the BMIOD 230. 

of the invention. As shown in FIG. 2, one or more processors In addition to its bridging capability, the HB2 232 

CPU1 204 and CPU2 208 are connected to a Host bus 210. 55 includes a memory controller (not shown) which comprises 

The CPU1 204 and CPU2 208 may be the Pentium II or a DRAM Controller, a Data Path, and one or more Memory 

Pentium Pro (P6) processors manufactured by Intel Corpo- Interface Components. The combined memory controller 

ration. Using the P6 processors, the Host bus 210 is com- on e physical load on the memory bus. The memory 

monly referred to as the P6 bus. The P6 bus supports controller includes two sets of registers (I/O space registers 

multiple, pipelined transactions having data transfers of four 60 aQ d configuration registers). Examples of the memory con- 

64-bit wide words (commonly referred to as a "cache line" trailer components include the 82453KX/GX DRAM 

transfer). A host bridge (HB1) 214 is connected to the Host Controller, 82452KX/GX Memory Data Path, and 

bus 210 to support communication between the Host bus 82451KX/GX Memory Interface Component manufactured 

210 and other buses in the system, such as a PCI1 bus 218 bv IntcI Corporation. 

and an input/output device (IOD) bus 220. One or more I/O 65 FIG. 3 is a functional block diagram of the Host bridge 

devices may be connected to the PCI1 bus 218, such as HB1 214 as used in the computer system of FIG. 2. As noted 

IOD1 222 and IOD2 226. The devices IOD1 222 and IOD2 above, the HB2 232 of FIG. 2 may be designed and 
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implemented as the HB1 214 FIG. 3. The HB1 214 com- 
prises a Host Master (HM) 310, an integrated driver elec- 
tronics (IDE) Controller 320, and an Internal Control Bus 
("IC bus") 330 which supports internal communication 
between the IDE Controller 320 and the HM 310. The HM 5 
310 performs several bridging functions including conver- 
sion of signal protocols between secondary buses and the 
Host bus 210. Additionally, the HM 310 supports deferred 
transactions over the Host bus 210. The IDE Controller 320 
conforms to the disk interface standard based on the IBM 10 
industry standard architecture (IS A) 16-bit bus. The IDE 
Controller 320 controls the transfer of signal traffic between 
bus mastering IODs, such as the BMIOD 230, and the main 
processor, e.g., CPU1 204 or CPU2 208 (FIG. 2). 
Additionally, the IDE Controller 320 controls the transfer of 15 
signal traffic between the BMIOD 230 and the main memory 
244 or other IODs in the system. 

The HM 310 accepts and arbitrates requests received from 
PCI targets, PCI requesters, and IDE controllers. The HM 
310 issues these requests to the Host bus 210. The HM 310 2 o 
receives these requests from requesters via the IC bus 330. 
The HM 310 comprises one or more host bus interface 
modules (HIMs), a host master requester (HMR), a host 
master arbiter (HMA), an in-order queue (IOQ), a host 
master snooper (HMS), and a host master responder (HMP) 2 s 
(not shown in this figure). During each clock cycle, the 
HIMs register all input signals received by the HM 310 from 
the Host bus 210. All signals are first registered before the 
HM 310 makes any logic decision. The HMR accepts 
requests from and arbitrates access among up to four dif- 30 
ferent requesters. The HMR generates one or more flag 
signals to the HMA to initiate arbitration. The HMR buffers 
the first request received from a requester, and holds off any 
subsequent requests from that requester until the first request 
is executed. The HMR further formats and provides signals 35 
to the Host bus 210. 

The HMA arbitrates access to the Host bus 210 among 
several requesters. The HMA further maintains and tracks 
the state of the Host bus 210. The state of the Host bus 210 
may be free, throttled, or stalled. In the free state, the HM 40 
310 may issue requests freely over the Host bus 210. In the 
throttled state, the HM 310 may issue only one request over 
the Host bus 210. In the stalled state, the HM 310 may not 
issue any requests over the Host bus 210. The IOQ is a 
register which stores information about (up to eight) trans- 45 
actions which may be outstanding on the Host bus 210. The 
IOQ stores request codes (each identifying the requester 
which issued the request, i.e., an IDE or PCI device), byte 
enables, length of transaction, command codes (type of 
transaction), and a snoop done bit. The snoop done bit 50 
indicates that the snoop phase is complete. As specified in 
Intel's Pentium II or Pentium Pro processor standard, the 
snoop phase occurs during a bus transaction and is con- 
trolled by the HIT# (hit), HITM# (hit modified), and 
DEFER# (defer) host bus interface signals. The IOQ bead 55 
indicates which transaction to be completed next on the Host 
bus 210. The IOQ tail indicates the next position in the IOQ 
to be filled. The HMS samples one or more snoop signals, 
and tracks the "snoop stall" state to determine when the 
snoop phase is complete. The HMP tracks the response 60 
phase on, provides the write data to, and accepts the read 
data from the Host bus 210. 

The IC bus 330 comprises a 32- or 36-bit address bus and 
a 64-bit data bus for supporting communication between the 
IDE controller 320 and the HM 310. There are several IC 65 
bus interface signals which characterize the operation of the 
IC bus 330. The interface signals include: REQ, REQ_ 
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BUSY, ADDR, BE, COUNT, STATUS, REQ__RETRY, 
REQ_DEFER, DEFER_ENABLE, DEFER_ID, DATA_ 
DEFER, DATA_RETRY, WRITE_STROBE, WRITE_ 
DATA, WRITE_BUSY, WRTIE_COMPLETE, READ_ 
STROBE, READ_DATA, AND READ_BUSY. The REQ 
signal is asserted by a requester device to request the transfer 
of certain data from a target device. In one embodiment, if 
the requester is provided with capability for multiple out- 
standing requests, then multiple REQ signals may be 
asserted by the same requester on the IC bus 330. The 
requester and target device arc responsible for keeping track 
of their respective outstanding transactions. 

The REQ__BUSY signal represents the commonly known 
handshake signal between devices. The REQ_BUSY signal 
is typically issued by the target to the requester to indicate 
that the target is ready to receive the request command. By 
asserting the REQ_BUSY signal, the target further indicates 
that the target has read the address, byte enables, count and 
status bits. The ADDR signal is a 32- or 36 -bit address signal 
which may be issued by any device, i.e., the requester or 
target, to indicate the device's address. The BE signal 
represents an 8-bit field for a byte enable asserted by the 
requester during a request transaction. The COUNT signal is 
a 2-bit field representing the type of transfer being requested. 
For example, a 00 represents one 64-bit transfer, 01 repre- 
sents two 64-bit transfers, 10 represents three 64-bit transfer, 
and 11 represents four 64-bit transfers, between the 
requester and target. The STATUS signal is a multi-bit field 
representing the type of request. For instance, a 0000 is an 
interrupt acknowledge, 0001 is a special cycle, 0010 is an 
I/O read, 0011 is an I/O write, 0110 is a memory read, 0111 
is a memory write, 1010 is a config read, 1011 is a config 
write, and 1110 is a defer enable. 

The REQ_RETRY signal is asserted by the target to the 
requester indicating that the preceding request should be 
retransmitted by the requester. Typically, a target asserts the 
REQ_RETRY signal when the target has lost and is unable 
to recover the request, or the target is not ready to process 
the request at the time it was received. The REQ_DEFER 
signal is asserted by the target to the requester indicating that 
the request has been deferred for execution at a later time. 
By asserting the REQ__DEFER signal, the target advises the 
requester to remove the request from the requester's IOQ 
and release the bus. A deferred response is possible when the 
defer enable of the STATUS signal is asserted. The 
DEFER_ENABLE signal is asserted by a requester to 
indicate that the requester supports deferred transactions if 
the target device is not available to execute the request 
promptly. The DEFER_ID signal is asserted by both the 
requester and target devices to keep track of the identity and 
order of the defer transaction in the request queue. The 
DATA_DEFER signal is asserted by the target to the 
requester indicating that the data is now being sent in 
response to the deferred request. 

The WRITE_STROBE signal indicates that the write 
data is valid from the requester for data transfer to the target. 
The WRITE_DATA signal indicates the 64-bit on the data 
bus to be written by the requester into the target. The 
WRITE_COMPLETE signal is a response issued by the 
target to the requester indicating that the target has com- 
pleted servicing the write request at the top of the IOQ. The 
READ_STROBE signal is a command issued by the target 
to the requester indicating that the read data is valid for data 
transfer to the requester. The READ_DATA signal indicates 
the 64 -bit on the data bus to be read by the target into the 
requester. The READ_BUSY signal is a response issued by 
the requester to the target indicating that the data path in the 
requester is presently busy and, thus, not available to receive 
the read data. 
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The IDE controller 320 and the HM 310 manipulate the 
above signals in conformance with the protocol of the ICbus 
330 to communicate requests between IODs and the Host 
bus 210. FIG. 4 is a flow chart describing the execution of 
a bus transaction in the computer system of FIG. 2. As 
shown in FIG. 4, the process typically begins at step 400 
when the main processor, e.g., CPU1 204 or CPU2 208, 
configures the IDE Controller 320 and I/O devices, e.g., the 
BMIOD 230. The BMIOD 230 issues a read request to the 
IDE Controller 320 via the IOD bus 220 indicating its intent 
to read data from a target device in the system. The read 
request includes, among other things, the address of the 
target device, location of the data in the memory space of the 
target device, and other control and identification informa- 
tion. At step 410, the IDE Controller 320 acknowledges the 
read request and issues a cache line read (i.e., 4x64 bits) over 
the IC bus 330 (FIG. 3). To initiate a cache line read request, 
the IDE Controller 320 asserts the REQ signal on the IC bus 
330 to the HM 310. At step 420, the HM 310 acknowledges 
the cache line read request and, when ready to execute the 
request, accepts the request by asserting a REQ_BUSY 
signal and REQ_DEFER signal on the IC bus 330. As noted 
above, by asserting the REQ JUSY signal, the HM 310 
establishes a handshake with the IDE Controller 320 to 
indicate that the HM 210 is ready to accept the request 
information. In establishing a handshake, the active or 
asserted REQ„BUSY signal occurs when the signal is at a 
low voltage level. By asserting the REQ_DEFER signal, the 
HM 310 indicates to the IDE Controller 320 that the request 
may be deferred by the target, in the event that the target is 
not ready to execute the request promptly. 

As noted above, in this embodiment, the Host bus 210 
may be a P6 bus as specified by the Pentium II or Pentium 
Pro processor's standard of Intel Corporation. Hence, the 
Host bus 210 conforms to the host bus interface signals 
specified by the Pentium II or Pentium Pro processor bus. 
The Pentium II or Pentium Pro processor bus standard 
designates the EXF#1 as the extended function signal for 
Defer Enable to support deferred transactions. Pursuant to 
the Pentium II or Pentium Pro specifications, the symbol 
at the end of the signal name indicates that the active, i.e., 
asserted state occurs when the signal is at a low voltage 
level. At step 430, the HM 310 issues a cache line read 
request over the Host bus 210 with the Defer Enable signal 
asserted. In addition to asserting the Defer Enable signal, the 
HM 310 includes a unique Defer ID X to identify or tag the 
defer transaction so that the requester recognizes the defer 
response upon receipt. At step 440, the target HB2 232 
detects and accepts the cache line read request based on the 
target address information contained therein. Hence, for 
example, if the read request is destined to the main memory 
244, then the read request contains address information 
indicating the main memory 244 as its destination, i.e., 
target. Thus, the HB2 232 recognizes that the request on the 
Host bus 210 belongs to the main memory 244 (which is 
connected to the HB2 232) based on the address information 
of the main memory 244. 

At step 450, the HB2 232 issues the cache line read 
request on the bus (e.g., memory bus 240) connected to the 
target device, e.g., the main memory 244. The target, in turn, 
receives the cache line read request and, if not busy, returns 
the desired data in response to the read request having a 
destination address of the requester device, i.e., BMIOD 
230. If the target is busy, or data is not available, the target 
defers its response and instructs the HB2 232 to release the 
Host bus 210 to execute other transactions. When the target 
is ready, the target returns the desired data to the requester 
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via the HB2 232. At step 460, the HM 310 detects the data 
incoming from the target and returns the data to the IDE 
Controller 320 via the IC bus 330. In conformance with the 
IC bus signal interface, the HM 310 returns the data with the 

5 DATA_DEFER signal asserted to indicate that this is the 
data response from the previous deferred request. The IDE 
Controller 320 forwards the data to the requester BMIOD 
230. At step 470, the IDE Controller 320 determines if there 
are any more cache line read requests to be performed. More 

to read requests may be needed if the requester desires addi- 
tional data which were not contained in the received cache 
line read. If the IDE Controller 320 determines that there are 
more cache line reads desired, then the process starts over at 
step 410. If no more cache line reads are desired, then the 

is process terminates at step 480. 

FIG. 5 is a timing diagram for a deferred transaction as 
executed by the IC bus of FIG. 3. The timing diagram 500 
shows the logical states of the various interface signals of the 
IC bus 330 during a deferred read transaction as a function 

20 of time. The IDE Controller 320 and the HM 310 manipulate 
interface signals in the timing diagram 500 during a deferred 
read transaction. As shown in FIG. 5, the HCLK 504 is a 
clock signal controlling the timing of the various interface 
signal transitions during a transaction on the I C bus 330. A 

25 timescale 530 in nanoseconds (nsec.) is shown to indicate 
the time separation between various timing events. As 
shown in FIG. 5, at about 4 nsec., the IDE Controller 320 
asserts a REQ signal 508 to request a read operation from a 
target device. At about 18 nsec, the HM 310 responds to the 

30 REQ signal 508 by asserting a low REQ_BUSY signal 512 
to indicate that it is ready to accept the request commands 
(i.e., data) from the IDE Controller 320. During the duration 
of the low REQ_BUS Y signal 512, the HM 310 captures the 
flow of data from the IDE Controller 320 including the 

35 ADDR signal 516, the BE signal 520, COUNT signal 524, 
and STATUS signal 528. Moreover, at substantially the same 
time as the transition of the REQ_BUSY signal to low, the 
HM 310 asserts the REQ_DEFER signal thereby indicating 
to the IDE Controller 320 that the request may be deferred 

40 by the target device. Finally, the RETRY signal 536 is kept 
low during the entire duration of the transaction on the IC 
bus 330 thereby indicating that no retry transaction will 
occur. 

45 In view of the foregoing, it will be appreciated that the 
invention overcomes the long-standing need for a method of 
peer-to-peer mastering over a computer bus, e.g., the P6 bus. 
The method provides the ability for master devices, e.g., 
host bridges, to defer bus transactions without the disadvan- 
tages of tying up the host bus or issuing retry transactions. 
The invention may be embodied in other specific forms 
without departing from its spirit or essential characteristics. 
The described embodiment is to be considered in all respects 
only as illustrative and not restrictive. The scope of the 
5S invention is, therefore, indicated by the appended claims 
rather than by the foregoing description. All changes which 
come within the meaning and range of equivalency of the 
claims are to be embraced within their scope. 
What is claimed is: 
w 1. In a computer system having a main processor con- 
nected to a host bus, a method of communication between at 
least one requester, connected to a first bus, and at least one 
target, connected to a second bus, the method comprising: 
instructing a first device to receive a request from the 
55 requester via the first bus; 

sending the request by the first device to a second device 
via the host bus; 
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asserting a defer enable signal by the first device via the 
host bus; and 

deferring response by the target when the target is 
unavailable to respond. 

2. The method as defined in claim 1, wherein the act of 
sending the request by the first device via the host bus 
includes the act of issuing a cache line read request via the 
host bus. 

3. The method as defined in claim 1, wherein the act of 
instructing the first device includes the act of issuing a 
request by an IDE Controller to a host master via an internal 
control bus. 

4. The method as defined in claim 1, wherein the act of 
instructing the first device includes the act of establishing a 
handshake between an IDE Controller and a host master. 

5. The method as defined in claim 1, wherein the act of 
sending the request by the first device via the host bus 
includes the act of issuing a cache line read request by the 
first device via a P6 bus, 

6. The method as defined in claim 1, wherein the method 
further comprises the act of issuing the request by the 
requester to an IDE Controller 

7. The method as defined in claim 1, wherein the method 
further comprises the act of accepting the request and a defer 
enable signal by the second device. 

8. The method as defined in claim 1, wherein the method 
further comprises the act of issuing a request having a defer 
enable signal by the second device via the second bus. 

9. The method as defined in claim 1, wherein the com- 
munication between the requester and the target involves at 
least one device other than the main processor. 
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10. In a computer system having at least one main 
processor connected to a host bus, a method of communi- 
cation between at least one requester connected to a first bus 
and at least one target connected to a second bus, the method 
comprising: 

issuing a request by the requester via the first bus to a first 
device; 

forwarding the request with a defer enable signal by the 
first device to a second device via the host bus; 

receiving the request by the second device from the first 
device via the host bus; 

sending the request by the second device to the target via 
the second bus. amJ 

deferring response to the requester when the target is 
unavailable to respond. 

11. The method as defined in claim 10, wherein the act of 
issuing the request by the requester includes the act of 
issuing the request by an IDE controller to the first device. 

12. The method as defined in claim 10, wherein the act of 
forwarding the request with a defer enable signal by the first 
device includes the act of forwarding a cache line read 
request via the host bus. 

13. The method as defined in claim 10, wherein the act of 
deferring the response to the requester includes the act of 
transmitting the deferred response from a PCI device. 
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